Since two or more Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, authentication requests made from one domain to another are successfully routed in order to provide a seamless coexistence of resources across domains. Users can only gain access to resources in other domains after first being authenticated in their own domain.
Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications using one of two authentication protocols: Kerberos V5 or NTLM. For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication. For more information about the Active Directory authentication process, see Access control in Active Directory.
Once authenticated, the user can attempt to gain access to resources from any domain in the forest using the Active Directory authorization process. For more information about the Active Directory authorization process, see Security information for Active Directory.
To access a shared resource in another domain using Kerberos, a user's workstation first requests a ticket from a domain controller in its account domain to the server (hosting the resource) in the trusting domain. This ticket is then issued by an intermediary trusted by the workstation and the server. The workstation presents this trusted ticket to the server in the trusting domain for authentication.
The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when a computer running Windows 2000 Professional, Windows 2000 Server,
Each domain has its own set of security policies that do not cross from one domain to another. For more information, see Domains.
It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each domain in a single forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple forests, see Accessing resources across forests.
It is important to understand the following security group concepts before you begin the planning process:
Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.
By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other domains. Consider the following best practices:
For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting Department to the Accounting Department global group.
For example, employees in the Sales Department and Accounting Department global groups located in DomainA use similar print resources located in DomainB. To make future administration changes more flexible, create a domain local group called Print Resources in DomainB, and add as members both the Sales Department and Accounting Department global groups in DomainA.
For example, assign permissions to the Print Resources domain local group located in DomainB so that its members, including the Sales Department and Accounting Department groups from DomainA, can access the printer located in DomainB.
Using Active Directory Domains and Trusts, you can determine the scope of authentication between two domains that are joined by an external trust. You can set selective authentication differently for outgoing and incoming external trusts. With selective trusts, administrators can make flexible access control decisions between external domains. For more information about how to set selective authentication, see To select the scope of authentication for users.
If you use domain-wide authentication on the incoming external trust, users in the second domain would have the same level of access to resources in the local domain as users who belong to the local domain. For example, if DomainA has an incoming external trust from DomainB and domain-wide authentication is used, any user from DomainB would be able to access any resource in DomainA (assuming that they have the required permissions).
If you set selective authentication on an incoming external trust, you need to manually assign permissions on each resource to which you want users in the second domain to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the external domain.
When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, if the Other Organization SID is not already present, then the server adds the This Organization SID. Only one of these special SIDs can be present in an authenticated user's context.
Administrators in each domain can add objects from one domain to access control lists (ACLs) on shared resources in the other domain. You can use the ACL editor to add or remove objects residing in one domain to ACLs on resources in the other domain. For more information about how to set permissions on resources, see To set permissions on a shared resource.
For information about setting authentication restrictions for multiple forests, see Accessing resources across forests.